Sounds like you know much more about WASI interfaces than myself.

The only thing I can say is that this adds another dependency — but if wasi-core becomes a dependency of std anyway this doesn't matter.

Since both the libc interface and the wasi-core interfaces are explicitly unstable there may not be much reason to choose one over the other for now — will breaking changes in each crate require bumping the minor version @sunfishcode?

As we thought about it more, the name "WASI core" has caused confusion in some places, so I've now renamed the "wasi-core" crate to "wasi". I'd also request holding off on merging this for just a while longer while we let the module naming scheme within the crate settle in a little more.

But beyond that, I am starting to see the role for this "wasi" crate emerge. It's a minimal and no_std crate which we can add as a dependency to libc, and which can track WASI API changes over time, possibly including adding backwards-compatibility interfaces to help smooth over API transitions.

So yeah, I think this PR here is good, just update the crate name and give it a little more time while we settle any remaining organizational issues :-).

Done! I will wait for your word then before merging this PR. (BTW maybe it's worth to release an empty wasi-core v0.3 with description "use wasi crate instead" or something similar?)

the name "WASI core" has caused confusion in some places, so I've now renamed the "wasi-core" crate to "wasi"

Well, I thought wasi-core for WASI Core API was a pretty straightforward naming, but oh well. :)

@sunfishcode
Can we merge this PR or do you plan to introduce changes to the wasi crate in the near future?

Sorry for being slow on my end; merging this sounds good to me.